The Advanced Access Content System (AACS) is a specification developed and managed under the direction of the Advanced Access Content System Licensing Administrator (AACS LA) that provides a secure means to distribute movie content to users in the marketplace. Content encoded with the AACS is encrypted such that a “Title Key” is used to decrypt the content within a player. The term “Title Key” and other terms used herein are to be construed to be used in a manner consistent with that of the AACS specifications. Refer to the AACS Introduction and Common Cryptography Elements specification for details regarding key management. The Title Key is encrypted using a tree-based Media Key Block (MKB). The MKB is based on player unique, AACS LA assigned, Device Keys, and the use of Broadcast Encryption whereby non-compliant players can be revoked, e.g. excluded from receiving the Title Key for new titles. Non-revoked players can calculate one of the Media Keys in the AACS MKB, and therefore decrypt the Title Key.
A Title Key must, by its very nature, remain confidential. There is no traceability inherent in a Title Key that is disseminated and used to encrypt thousands or even hundreds of thousands of copies of a Title. If a Title Key is compromised and posted on the Internet, a hacker can use it to ignore AACS compliance rules with a non-licensed and non-compliant player. The player can rip the encrypted content from the package media or stream, copy it, optionally down-res and re-encode it, and then distributed it for free over the Internet. Exposure of the Title Key can destroy the ability of the artists and creators of the content to profit from their labor. Needless to say, content security would be more robust if the Title Key remained secret!
It would be useful to forensically know what playback device leaked a Title Key that was made public in order to revoke it. By way of example, one method, which the AACS has provided as an option, implements such a mechanism for identifying a compromised player called Sequence Keys and the Sequence Key Block (SKB). Sets of Sequence Keys are assigned to individual players by the AACS LA. AACS copies multiple segments of content. AACS then encrypts the multiple segments of content using keys derived from the Sequence Keys, the Sequence Key Block (SKB) and the Title Key to effectively create sets of what we will call “sub-Title Keys” that will decrypt the common non-multiple encrypted segments as well as the multiple encrypted segments of content. The exact method in which sub-Title Keys are generated from the Sequence Keys, the SKB and the Title Key is not discussed here. Please reference the Advanced Access Content System: Pre-recorded Video Book specification.
With AACS Sequence Keys and the SKB, there is no longer a single key which will decrypt all the content. The process effectively splinters the single Title Key into many sets of what we will call “sub-Title Keys”. Certain content segments are replicated and a sub-Title Key is applied to each copy of the segment. Since each player derives a unique set of sub-Title Keys that will allow it to decrypt common and encrypted content segments, if they are made public, they could be forensically analyzed to identify the player from which they leaked.
The Sequence Keys and SLB method for identifying a compromised player suffers from some shortcomings. When implementing sub-Title Keys as provided by the AACS specification, segments of content must be copied. A segment may be composed of entire scenes of content which must be 100% copied for as many sub-Title Keys as are to be used for that segment. Depending on the AACS Sequence Keys and SLB key management, hundreds and, possibly, a thousand, sub-Title Keys may be required to encrypt all identified content segments. Content segments to be encrypted can be as much as about 10 seconds in duration. Segments must be of a long enough duration that if the key were missing, and the segment could not be decrypted, then the content would be significantly degraded. In other words, with missing content, the enjoyment that hackers would receive from watching the content would be affected.
In one exemplary embodiment, assuming 500 encrypted content segments (using sub-Title Keys), then 500 encryption actions×10 seconds/encryption=5,000 seconds or 83 minutes or 1.39 hours of extra content that needs to be streamed or delivered on the package media when implementing the security protection provided by Sequence Keys. This is a huge amount of extra data that must be processed for essentially the same content. It provides no extra benefit to the consumer, such as extra content that details how the movie was made or interviews with the director and actors. It dramatically increases the file size as well as the bandwidth required to stream content. Because of the large amount of additional content that must be added when implementing the Sequence Key security provision within AACS, few providers of content have been inclined to use Sequence Keys.
Additionally, each 10 second branch must be identified and pre-signaled in order for a player to properly select one of the plurality of encrypted segments that could be decrypt. A particular sub-Title Key that was derived from a player's Sequence Keys and SKB can only decrypt a particular segment. That segment must be navigated. The extra content is so voluminous due to the requirement for 100% encryption of the segments that special navigation is required similar to that used for alternate scenes or alternate endings, except that in this case, it is for alternate encryption (with the content being the same). This adds complexity to the navigation of a player.